1. Field of the Invention
The present invention relates to processing data packets communicated over a network; and, in particular, to separately accounting for multiple transactions in the same TCP data packets.
2. Description of the Related Art
Networks of general purpose computer systems connected by external communication links are well known and widely used in commerce. The networks often include one or more network devices that facilitate the passage of information between the computer systems. A network node is a network device or computer system connected by the communication links.
Information is exchanged between network nodes according to one or more of many well known, new or still developing protocols. In this context, a “protocol” consists of a set of rules defining how the nodes interact with each other based on information sent over the communication links. The protocols are effective at different layers of operation within each node, from generating and receiving physical signals of various types, to selecting a link for transferring those signals, to the format of information indicated by those signals, to identifying which software application executing on a computer system sends or receives the information. The conceptually different layers of protocols for exchanging information over a network are described in the Open Systems Interconnection (OSI) Reference Model. The OSI Reference Model is generally described in more detail in Section 1.1 of the reference book entitled Interconnections Second Edition, by Radia Perlman, published September 1999, which is hereby incorporated by reference as though fully set forth herein.
Communications between nodes are typically effected by exchanging discrete packets of data. Each packet typically comprises 1] header information associated with a particular protocol, and 2] payload information that follows the header information and contains information that may be processed independently of that particular protocol. In some protocols, the packet includes 3] trailer information following the payload and indicating the end of the payload information. The header includes information such as the source of the packet, its destination, the length of the payload, and other properties used by the protocol. Often, the data in the payload for the particular protocol includes a header and payload for a different protocol associated with a different, usually higher layer of the OSI Reference Model. The header for a particular protocol typically indicates a type for the next protocol contained in its payload. The payload protocol is said to be encapsulated in the header protocol. The headers included in a packet traversing multiple heterogeneous networks, such as the Internet, typically include: a physical (layer 1) header; a data-link (layer 2) header; an internetwork (layer 3) header (such as an Internet Protocol, IP, header); a transport (layer 4) header (such as a Transport Control Protocol, TCP, header); and one or more applications layers (layers 5, 6, 7) as defined by the Open Systems Interconnection (OSI) Reference Model.
A widely used application layer (layer 7) protocol is the Hypertext Transfer Protocol (HTTP) which is used to access and transport data files (called documents) that may have links to other documents, such as Hypertext Markup Language (HTML) documents commonly known as Web pages. HTTP version 1.1 (HTTP 1.1) is described at the time of this writing in Internet Engineering Task Force (IETF) request for comments (RFC) 2616 which can be found in a file named rfc2616.txt, which can be found, along with other RFC files, at the world wide web domain www.ietf.org in the file directory named rfc. The entire contents of RFC 2616 are hereby incorporated by reference as if fully set forth herein. Any document that may be transferred using HTTP is an HTTP resource. HTTP resources include Web pages, text, audio, images and video.
A resource is transmitted using HTTP from an HTTP server (often called a Web server) to an HTTP client (often called a Web browser, or, simply, browser) in response to a request from the HTTP client. The client-server model of computer process interaction is widely known and used in commerce. According to the client-server model, a client process sends a message including a request to a server process, and the server process responds by providing a service. The server process may also return a message with a response to the client process. Often the client process and server process execute on different computer devices, called hosts, and communicate via a network using one or more protocols for network communications. The term “server” is conventionally used to refer to the process that provides the service, or the host computer on which the process operates. Similarly, the term “client” is conventionally used to refer to the process that makes the request, or the host computer on which the process operates. As used herein, the terms “client” and “server” refer to the processes, rather than the host computers, unless otherwise clear from the context. In addition, the process performed by a server can be broken up to run as multiple servers on multiple hosts (sometimes called tiers) for reasons that include reliability, scalability, and redundancy, but not limited to those reasons. As used herein, a single HTTP transaction is a single request for a HTTP resource and the HTTP resource returned to the HTTP client in response to that request.
With recent technological advances, various specialized and mobile devices have participated in network communications, including HTTP transactions. Such devices include, but are not limited to, wireless telephones, personal digital assistants (PDAs), electronic notebooks, household appliances, devices for human interface, and other devices capable of initiating or receiving voice or data communicated over a network. Network communications with such devices are often routed through a server called a Service Gateway (SG). The SG performs various functions for the device, such as reformatting resources for the special characteristics of the device. Some services are subscriber aware and determine the subscriber associated with a device by monitoring messages exchanged between the device and an Authentication, Authorization, and Accounting (AAA) server. AAA servers are widely known in the art and include Remote Authentication for Dial In User Service (RADIUS) servers, Diameter servers, and Terminal Access Controller Access Control System (TACACS) servers. Various subscriber-aware services are known, such as filtering data by content, filtering by source (e.g., firewall services), data compression for faster transfers, encryption, and guaranteeing a minimum quality of service to support high throughput and delay sensitive communications like voice over IP, among others.
Many services provided by a SG are paid for based on the amount of usage; and the SG thus tallies usage for billing purposes. In a common mode of operation, the SG charges for the total number of IP bytes of an HTTP transaction transferred between a client and a server. The HTTP transaction data is carried by a sequence of IP datagrams. An IP datagram is the portion of a data packet that includes the IP header and the IP payload. The total number of IP bytes in an IP datagram is the sum of the bytes in the IP header and payload, which includes the TCP header and the TCP payload in TCP/IP packets. This number is given in the IP Total Length field in the IP header.
With HTTP 1.0, a TCP session may transport multiple HTTP requests. A TCP session begins with a TCP SYN data packet and ends with a TCP FIN data packet, as is well known in the art. (See for example, W. Richard Stevens, TCP/IP Illustrated Volume 1, The Protocols, Addison Wesley Professional, Boston, 1994, the entire contents of which are hereby incorporated by reference as if fully set forth herein.) Within the TCP session, the client sends HTTP requests sequentially; e.g., request N+1 is not sent until the client receives the entire response for request N. As a result, the IP bytes for an IP datagram are easily correlated to a single HTTP transaction, and the SG can charge all bytes in an IP datagram to the current HTTP transaction for the TCP session.
With HTTP 1.1, a TCP session may transport multiple HTTP requests, and the client may have multiple HTTP requests outstanding; e.g., request N+1, N+2, N+3 may be sent to the server before the client receives all the data for request N. As a result, a single IP datagram may contain request data or response data for multiple HTTP transactions. The method of assigning the value of the IP Total Length field in the IP header to the current HTTP transaction for the TCP session is no longer valid.
In one approach, all IP bytes are assigned to the first transaction in the data packet. For example, wireless devices use a Wireless Application Protocol (WAP) as an application layer protocol with a payload called a protocol data unit (PDU). Several PDUs are concatenated and translated to HTTP in a Wireless Service Gateway (WSG). When the WSG performs billing for concatenated WAP PDUs, it assigns all of the IP bytes to the first transaction in the packet.
While suitable for some purposes, there are disadvantages with the prior art approach. For example, HTTP content providers want to be compensated (or billed) in proportion to the amount of their content accessed by users. Users obtain access to the HTTP content though the network service providers, such as Internet Service Providers (ISPs), who provide the access points and the service gateways. Thus the ISPs want to bill the users or HTTP content providers in proportion to the users' use of the HTTP content. The prior art approach does not track users' access to all HTTP content, just the first HTTP transaction in a data packet. Consequently, the HTTP content provider for the first transaction is over compensated (or over billed); and the HTTP content providers for the second and subsequent transactions in the data packet are under-compensated (or under billed). HTTP content providers for the second and subsequent transactions would prefer to deal with ISPs that provide more differentiated billing platforms. Content providers often charge differentially for content, even from the same server. Some content may be free, some may be charged per transaction instead of per-byte, some may be charged at a different rate than others, all within the same TCP connection. For example, content providers may charge per-byte to browse ring tones, but may have a flat charge per downloaded ring tone. Similarly, text-messages are included in a base rate charged to content providers, but photo messages incur additional charges.
Based on the foregoing description, there is a clear need for techniques that separately account for multiple transactions in the same data packets communicated over a network. In particular, there is a need for techniques that apportion IP bytes to each of multiple HTTP transaction in a single TCP datagram based at least in part on the number of bytes each HTTP transaction includes.